Linkers for producing executable programs are known. Generally speaking, a linker acts to link a number of object code modules to form a single executable program. Object code modules are usually generated from program source code modules, these modules being written a high level language. An assembler/compiler reads each source code module and assembles and/or compiles the high level language of the source code module to produce an object code module. The assembler also generates a number of relocations that are used to combine the object code module at link time in a linker.
The ELF (executable linking format) standard defines a convention for naming relocation sections belonging to a given section, e.g. rel.abc is the relocation section of section .abc. Standard relocations under the ELF format allow an offset in section data to be defined where patching is to occur and a symbol whose value is to be patched. A type field also exists which is used to describe the appropriate method of encoding the value of the symbol into the instruction or data of the section data being patched. According to the existing arrangements, the relocation type definitions are usually created on an ad hoc basis for each instruction set targeted. The 32-bit ELF standard allows only 256 distinct relocation types, so that some types are re-ascribed to different semantics for each instruction set.
One problem that exists with existing linking techniques is that the object code module itself needs to define the necessary relocations to implement the calculations required to patch a single location for each such location in the section data in the module. For sections requiring a plurality of relocation operations, object code modules can become bloated. Moreover, it is frequently the case that the same sequence of relocation operations may be required to be implemented on different sets of section data.
According to existing techniques, it is necessary to redefine the sequence of relocations in each relocation section associated with a particular set of section data.
According to UK Patent Application no. 9925849.3 filed on 1, Nov. 1999 by the present applicant further relocation types, referred to as ‘special’ or ‘non-bit’ relocations, may be implemented, including a mechanism for defining and passing compound relocations in object files. A compound relocation is a relocation that is expanded by the linker into a sequence of relocations all at the same offset. Typically, it can be a set of “non-bit” relocations performing some calculation followed by a bit relocation patching the value into the section. The compound relocations allow a number of advantages to be gained. By defining a compound relocation for frequently performed calculations to encode symbols into instructions, object file bloat can be avoided. This can be thought of as a method of file compression. The decompression occurs at link time when the compound relocations are expanded into the full sequence of relocations.
To make use of compound relocations sequences of relocations are manually defined by the programmer as compound relocations identified by a number #n and the generated sequence of relocations is replaced by the corresponding compound relocation in the assembler generated object code module. When the linker encounters an R_COMPOUND relocation, it executes the defined sequence associated with the number #n. This requires each relocation sequence to be defined manually. Such manual programming work is time consuming and increases the possibility of errors being introduced. Furthermore, in the situation where the toolchain manufacturer has developed and used a new sequence of relocations then the end user will not know what the sequence of relocations is and so will be unable to define the required compound relocation without manually examining the assembler generated object code modules. For example, when the toolchain manufacturers has modified the compiler to emit a different assembly language idiom for some particular circumstances this may result in a different sequence of relocations being emitted.    e.g. MOV fred+offset, RØwould yield a different sequence from            MOV offset+fred, RØ        
Even though (in this case) the resultant executable code is the same.
When such changes are made it is desirable to have a method of reliably changing the sequence definitions used to give good compression.
It is an aim of the present invention to provide improved assembler functionality to reduce the manual programming work required and to allow an end user to use compound relocations more easily.